1. Field of the Invention
This invention relates generally to power systems, and DC power delivery, management and configuration. More specifically, the invention provides a system and method for event based sequencing and fault spreading in power management systems.
2. Description of the Related Art
Power supply design has become a much more critical and difficult task than it was a few years ago. High-current/low-voltage ICs typically require a very clean and stable source of DC power. The power source must be capable of delivering very fast current transients. The electronic path to these loads must also have low resistance and inductance (for example, a 1.5V supply would be completely dropped across a 25 mΩ resistance at 60 Amps). Power distribution in complex systems is often accomplished by distributing a high-voltage, low-current power source to a set of local direct-current to direct-current (DC-DC) converters. These converters, typically known as point-of-load (POL) devices and/or POL regulators (also referred to as POLs or POL converters), convert the higher voltage to a level more appropriate for the load or multiple loads that require power. Generally, each POL may be configured to generate a different voltage potential or multiple POLs may be configured to generate the same voltage potential. POLs generating the same voltage potential may be designed to drive separate loads. Similarly, two or more POLs may be connected in parallel to drive one or more common loads.
In systems that utilize multiple POL regulators, it is common for the POL regulators to exchange information in order to implement necessary power management features. Typical power management features include voltage tracking, load balancing, sequencing, phase spreading, clock synchronization, as well as many other functions not enumerated here. With the rising complexity and robustness requirements of many systems, the ability to monitor and control the power distribution sub-system has become increasingly more critical. Traditionally, information exchanged by POL regulators has been represented by analog voltage and/or current signals. There are, however, several advantages to representing the exchanged information as digital data that may be transferred across a bus interconnecting all related POL devices. Monitoring of power distribution sub-systems has typically been implemented via a standard digital interface coupling the major components of the power distribution system to a host microprocessor (or more generally, a Local Controller). The digital interface may allow the Local Controller to continuously monitor the health of the power system. It may also control the power system in order to implement system-level features such as standby and sleep modes.
One example of a digital interface that is well suited for such applications is the I2C (Inter-IC) bus. The I2C bus is a multi-master, multi-slave, two-wire bus that offers support for any device on the bus to access any other device. Transactions on the I2C bus typically consist of a start event, a destination slave address, a read/write bit, and a variable number of data bytes. The transactions are generally terminated by a stop event or another start event. The data byte immediately following the destination slave address may be interpreted as a command or tag byte, which identifies the nature and/or type of the packet. FIG. 1 shows the basic packet structure of a packet 100 that may be representative of communication packets used with a multi-master multi-slave bus, such as the I2C bus. Packet 100, which may contain data to be transferred or written to a slave device, may include a start bit “S” 20 signaling the beginning of the communication from the master. This may be followed by a unique slave address byte “ADR” 22, with the most significant bit (MSB) coming first. The subsequent Read/Write bit 24, typically the eighth bit overall, following “S” 20, specifies whether the slave is to receive (typically a ‘0’ value) or to transmit (typically a ‘1’ value). Read/Write bit 24 may be followed by an acknowledge bit “A” 26 issued by the receiving device, acknowledging receipt of the previous byte.
The transmitting device (slave or master, as indicated by the Read/Write bit) may then transmit a data byte 34 starting with the MSB. In the example packet of FIG. 1, the slave device is to receive and the first byte following slave address byte 22 is a command byte “CMD” 34 sent by the master device. At the end of the byte, the receiving device may issue a new “A” 28. This 9-bit pattern may be repeated until all the required bytes have been transmitted, in this case Data1 36 and Data2 38, and a respective acknowledge bit following each byte. In a write transaction, as illustrated in FIG. 1, when the master device is done transmitting, it may monitor the last acknowledge bit, that is, “A” 32, then issue a stop condition “P” 40. In a read transaction (slave device transmitting), the master device may not acknowledge final byte 38, thereby indicating to the slave device that the slave device's transmission is completed. The master device may then issue “P” 40.
FIG. 2 shows a typical configuration in which multiple POL regulators 102, 104, and 106 are coupled together via I2C bus 120 comprising data signal (SDA) line 124 and clock signal (SCA) line 122, which also couples a Local Controller 108 and other devices 110, 112, and 114 that are not POL regulators. Each of attached devices 102, 104, 106, 110, 112, and 114 must be responsive to a unique address, which is its respective slave address. The slave address may be defined for a device or programmed into a device in several possible ways. For example, the address may be “hard wired” into the device by design. Alternatively, the address may be determined by the connections of one or more pins on a device, with the one or more pins dedicated to selecting the address to which the device will respond. In yet another configuration, the device may contain non-volatile memory into which the slave address as well as other configuration information may be programmed during manufacturing or during a configuration operation performed to prepare the device for use in a particular system or application.
During operation, Local Controller 108 would typically address each POL regulator and/or other device, by using that POL regulator's or device's unique slave address as required, writing control information and reading status and data. FIG. 3 is a simplified illustration of a packet being transferred from Local Controller 108 to POL regulator 104. Each of the devices on shared I2C bus 120 will receive the packet sent by Local Controller 108. However, only POL regulator 104 would recognize the address at the start of the packet as its own. POL regulator 104 would thus respond to the packet initiated by Local Controller 108, receiving or supplying data as required.
FIG. 4 shows the basic bus waveforms on the shared SDA (410 and 412), and SCL (414) bus wires. The bus connections of each device connected to the bus are typically of an “open-drain” nature, with an external pull-up device, generally a resistor or current source (not shown), on each shared signal wire. Each device connected to the bus has the ability to drive the signals to a low or logic 0 level or to not drive it at all. If no device is “pulling” the bus low, the external pull-up typically causes the bus signal to remain at a high or logic 1 level. Also illustrated in FIG. 4 are, a transmission start event 402 corresponding for example to “S” bit 20 in FIG. 1, the MSB through LSB of a slave address byte corresponding to “ADR” 22, an acknowledge event 404 corresponding to “A” bit 26, followed by a data byte corresponding to Data2 38, and a stop event 406 corresponding for example to “P” bit 40.
Another bus standard, developed after the I2C bus standard, is the SMBus (System Management Bus), which is backward compatible with the I2C bus standard while introducing additional features to support error detection, hazard recovery, and dynamic address assignment among others. It should be noted that both the I2C bus and the SMBus have predefined means for identifying a slave or destination device, but neither has predefined means for identifying the master or source of a bus transaction, a feature that is oftentimes required for POL regulators to communicate with each other. The information transfer requirements of several common power management features implemented among POL regulators will now be presented below.
It is a common requirement that the POL regulators in a system enable and disable their power outputs in a predefined order, or sequence. This has commonly been called “sequencing”, and refers more generally to orderly turn-on and turn-off for a group of POL regulators, one following the other in a prescribed order, which is typically necessary to avoid both temporary and permanent interference with the operation of the system. The order is typically configured by defining, for a given device, an optional prequel device—a device that must turn on before the given device turns on—and an optional sequel device—a device that must turn off before the given device turns off. The sequencing is traditionally accomplished by connecting a “POWER GOOD” (PG) output pin of each POL regulator to an “ENABLE” (EN) input pin of the next POL regulator to be enabled. This is illustrated in FIG. 5, where the PG pin of POL regulator 202 is coupled to the EN pin of POL regulator 204, while the PG pin of POL regulator 204 is coupled to the EN pin of POL regulator 206. Each POL regulator may assert its PG pin when the output of the POL regulator has met some predefined condition or reached some predefined state. This event may then allow the next POL regulator to enable its output followed by asserting its own PG pin.
One power management function that is also related to sequencing is fault spreading. Fault spreading refers to a group of POL regulators collectively shutting down upon one or more POL regulators in the group detecting a hardware fault. Part of fault spreading also typically includes the POL regulators collectively retrying operation once all the POL regulators that have detected a hardware fault have transmitted indication of their ability to begin operating again, as determined by the POL regulators' own configuration and fault response programming. The operation is typically retried in accordance with the sequencing configuration of the POL regulators. For example (referring again to FIG. 3 as an example of a power management system containing POL regulators coupled together via a bus), local controller 108 may access the POL regulators using respective addresses assigned to the POL regulators for explicit prequel and sequel device addresses to establish sequencing relationships among devices. This fault spreading is a serial process usable only within a sequencing chain, and may not work for devices that are not part of a sequencing chain, and/or devices configured in different sequencing chains.
In such a configuration, fault spreading becomes dependent on the echoing of recognized fault event transmissions in order to reach devices in the chain that are distant from the fault originating device's direct sequel/prequel device relationships. It usually limits fault spreading to an individual sequencing chain and to only those devices within a chain that have a sequel or prequel device. This generally requires limiting the echoing of recognized fault event transmissions in order to avoid endless echoes, but makes it very hard for a chain to recognize and process multiple faults. Serial fault spreading generally adds substantial and uncertain delays. In many cases the latencies on the bus can be long enough for echoed faults to be recognized by the device with a primary hardware fault, interfering with that device's own retry attempt. The device may not be able to identify whether the recognized fault event transmission is a new fault found elsewhere in the chain, or the echo of its own fault. There is usually no proper way to apply the fault response and retry the count of a primary hardware fault to the faulted chain as a whole. Furthermore, a head-of-chain device without dependency on a sequel-device for power down sequencing would typically not be able to participate with recognized faults in fault spreading, which may necessitate defining a fault spreading address with no sequencing function.
Other corresponding issues related to the prior art will become apparent to one skilled in the art after comparing such prior art with the present invention as described herein.